fix(runtime): reserve iterator raw-field floor so own .next patches stop corrupting state (#9019) - #9066

sequenceDiagram
  participant JavaScript
  participant IteratorDispatcher
  participant IteratorObject
  participant BuiltinAdvance
  JavaScript->>IteratorDispatcher: call iterator next
  IteratorDispatcher->>IteratorObject: inspect own next
  IteratorObject-->>IteratorDispatcher: return patched closure or no override
  alt own next exists
    IteratorDispatcher-->>JavaScript: return patched iterator result
  else builtin path
    IteratorDispatcher->>BuiltinAdvance: advance raw iterator state
    BuiltinAdvance-->>JavaScript: return iterator result
  end

• Fix all pre-merge checks with AI

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

First: thank you — this fixes #9019, and the root cause is worse than my issue described. I had written that the manual .next() path was fine; you're right that it was the same corruption one step later, and my probe's manual cases simply didn't re-read field 0 before returning. The real defect — first user property landing on the backing-collection pointer — explains both the SIGSEGV and the silent done: true, which my issue treated as unrelated.

Verified against my original reproducer: exit 0 where main is 139, and byte-identical to node across patched .next() under for…of, a plain it.foo = 123 write, all four iterator families (map/set/array/string), a manually-driven patched Map iterator, and user keys surviving enumeration.

Holding on two gate failures, both real.

1. perry-runtime does not compile without the regex-engine feature

error[E0432]: unresolved import `match_all`
  --> crates/perry-runtime/src/regex.rs:69:9

mod match_all; (line 41) and the pub(crate) use (line 68) are both #[cfg(feature = "regex-engine")]; the pub use at line 69 is not. With the feature off the export names a module that doesn't exist.

This passes cargo test -p perry-runtime --lib (2811/0, default features on) and fails cargo check -p perry, which is why it's easy to miss — the same bin-crate blind spot that produced #9044. I didn't fix it because the choice isn't mechanical: the comment right below says REGEXP_STRING_ITERATOR_CLASS_ID stays ungated because the always-linked iterator-prototype dispatch references it, so gating the export may need a stub for the feature-off build rather than just a cfg. You know whether that dispatch must work with the engine compiled out.

2. Raw-handle ratchet (raw_handle_debt.py, in lint)

bare raw-handle reads: 969 (baseline 967)
  tail.rs: 14 bare reads exceeds its ceiling of 11
  reserved_floor.rs: 2 bare read(s) in a module with no ceiling

The new module lands at zero by default — unlisted modules are locked there — so its two bare reads need across_{mut,const,nanbox} or with_{mut,const}_ptr (#7341). Worth doing on the merits rather than to satisfy the gate: this PR is about raw field slots on objects that user code can now mutate, which is exactly where a stale pointer across an allocation point bites.

One pre-existing gap this does NOT fix (not a blocker)

Adding 12 properties to an iterator and deleting 10 loses the values of the survivors — Object.keys correctly reports p10,p11, but reading them gives undefined. Identical on main, so this PR neither causes nor worsens it, and the same shape on a plain object is correct on main, so it's iterator-specific rather than a general squeeze bug. Mentioning it because it sits inside the storage model you're rewriting; if the reserved floor makes it easy to fix, this is the PR that would naturally carry it. I'll file it separately otherwise.

Everything else: perry-runtime --lib 2811/0, reserved_floor 4/4, fmt --check, fragment correctly numbered, remaining 59 lint gates green.

Merged. Raw-handle ratchet is green on your update; I fixed the remaining compile blocker myself since it turned out to be a one-line accident rather than a design question.

And I owe you a correction on how I framed it. I said the choice "isn't mechanical" and might need a stub for the feature-off build. That was wrong — I hadn't diffed the line against main. What actually happened:

 #[cfg(feature = "regex-engine")]
+pub(crate) use match_all::dispatch_regexp_string_iterator_method_builtin;   ← inserted here
 pub use match_all::{ dispatch_regexp_string_iterator_method, … };

main had that #[cfg] attached to the pub use. Inserting a line directly beneath the attribute moved it onto the new export and left the original ungated. So the fix is simply a second #[cfg], not a stub — no dispatch redesign needed, and -p perry compiles again (main was exit 0 all along, confirming this was the branch's regression rather than pre-existing).

Worth naming the shape, because this is its third appearance in a week: an inserted line silently inherits the attribute or doc block above it. #9013 and #9030 were the same accident with doc comments — a new function absorbing the previous one's /// block, leaving the original undocumented. Attributes fail loudly at compile time if something exercises the configuration; doc comments never do.

The reason it hid: cargo test -p perry-runtime --lib builds with default features and passes 2812/0, while cargo check -p perry unifies features differently and fails. Same bin-crate blind spot as #9044, which is why perry --bins is now in my standard set.

Re-verified after the fix: #9019's reproducer exits 0 (main: 139) and is byte-identical to node across patched .next() under for…of, plain property writes, all four iterator families, a manually-driven patched Map iterator, and user keys surviving enumeration. perry-runtime --lib 2812/0, perry --bins 1066/0, fmt --check, run_lint_gates.sh all 60 gates passed; 2 CI-only skipped.

The pre-existing iterator gap I mentioned (values lost after a squeeze crossing the threshold) is unchanged — identical on main, correct for plain objects. I'll file it separately rather than hold this.

Closing the loop on the two holds (thanks for landing the cfg fix directly — same shape I had staged: the insertion had detached the attribute from the neighboring pub use):

• Raw-handle ratchet: those numbers were the state at 18d124f59; d908219e5 in the merged stack moved the seed to NaN-boxed handles and put the tail hook on the existing refresh_roots_after_alloc! macro. Bare run on the merged head: 964 (baseline 967), all ceilings.
• The survivor-values gap: root-caused, and it was worth the dig — not the squeeze, and not this PR's storage. The values sat intact in the overflow spill the whole time; the Map/Set-iterator arm in the by-name GET tail ended with if key_bytes != b"next" { return undefined }, so every non-next own-property read was short-circuited and the reserved-floor storage was write-only through that lane (IC lanes served some compiled reads, which is why single-property probes passed). Fix is up as fix(runtime): make iterator own properties readable; present-undefined .next throws (follow-up to #9066) #9075, with your exact 12-add/10-delete shape as a unit test and a gap case, byte-identical vs 26.5.1 — plus the it.next = undefined present-but-non-callable case from the inline review, and seed-failure now drops the write instead of proceeding onto field 0.

Filed along the way: #9068 (helper-family .next value read returns undefined — pre-existing, read-side) and #9072 (delete-during-forEach on Set/Map visits holes on clean main; A/B'd from the merge-base before attributing).